Using OCL Beyond Specifications

Despite of its important potential and role in defining a more rigorous modeling language and in designing and implementing safer applications, until today OCL was not used at its true value. Using the results obtained in implementing OCL support in ROCASE, and taking into account the conclusions obtained testing the tools mentioned at http://www.klasse.nl/ocl, the paper tries to analyze this state of facts. The requirements needed in order to obtain a strong OCL support are presented. The ROCASE OCL support beyond semantical analysis is presented by means of a real example. Finally the conclusions acquired in our activity are offered. 1 The state of the art OCL is widely used both to define the well-formedness rules for the UML metamodel, and to express constraints in UML models. Unfortunately, until now the use of the constraint language was mainly restrained to the specification level in almost all cases. Even at this level, the existent OCL Tools should be improved. The errors found in the UML specification represent a strong argument in this respect. On the other hand, more and more positions and decisions sustain the use of OCL beyond specifications. The pUML proposal [MML’00] stated very clearly that, first of all, OCL should be used in the “definition” and validation of UML concepts. The adoption of XMI as transfer standard for the UML models opened the way for using OCL to the validation of UML models against UML well-formedness rules. (The above mentioned checks can be realized only if the tool has an OCL support and if the user has access to the UML metamodel level, in spite of the fact that in the 1.4 version, OCL doesn’t have an “official” metamodel). The UML models’ business rules cannot be taken into consideration if the model that includes them does not respect the UML syntax and semantic. It this context, it is not difficult to guess that the construction of safer applications modeled using UML, cannot be conceived without a strong OCL support beginning with the specification phase and finishing with the testing phase. Today, the support offered by the Case Tools is far from what it should be. This state of fact influenced in a negative way the performances obtained using UML and even the 1 A part of the results presented in this paper, were obtained in the NEPTUNE IST 1999-20017 framework 2 Computer Science Research Laboratory, “Babes-Bolyai” University 3 ROCASE – UML CASE tool conceived, designed and implemented at the “Babes-Bolyai” University, Computer Science Research Laboratory http://lci.cs.ubbcluj.ro/rocase.htm